home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11095 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB
  1. Path: camelot.dsccc.com!not-for-mail
  2. From: kcline@sun152.spd.dsccc.com (Kevin Cline)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 12 Mar 1996 11:32:18 -0600
  6. Organization: DSC Communications Corporation Switch Products Division
  7. Message-ID: <4i4cf2$crm@sun152.spd.dsccc.com>
  8. References: <JSA.96Feb16135027@organon.com> <adaworksDnrqsE.LpC@netcom.com> <4hhred$1rn@sun152.spd.dsccc.com> <4i19mg$vkt@azure.dstc.edu.au>
  9. NNTP-Posting-Host: sun152.spd.dsccc.com
  10.  
  11. In article <4i19mg$vkt@azure.dstc.edu.au>,
  12. Stephen Crawley <crawley@dstc.edu.au> wrote:
  13.  >In article <4hhred$1rn@sun152.spd.dsccc.com>,
  14.  >Kevin Cline <kcline@sun152.spd.dsccc.com> wrote:
  15.  >>
  16.  >>Well, I will now enumerate the difficulties I had porting an Ada program
  17.  >>with a Motif user interface from the TeleSoft compiler for Sparc-SunOS to
  18.  >>the Verdix compiler for MIPS/IRIX circa 1990:
  19.  >>
  20.  >>1. The TeleSoft compiler came with the IEEE Ada-POSIX bindings.
  21.  >>   The Verdix compiler did not; instead it supported a Verdix-defined
  22.  >>   API for UNIX services that was radically different.
  23.  >
  24.  >This is not a problem that can be blamed on the Ada language but on
  25.  >  a) late development of standardised Ada bindings and
  26.  >  b) unwillingness by Verdix to implement the standard when it 
  27.  >     arrived, maybe as an indirect consequence of a)
  28.  
  29. I wasn't trying to place blame; I'm trying to explain to Ada advocates
  30. why most PC and UNIX software developers were (and still are)
  31. uninterested in Ada, despite the well-known pitfalls in C development.
  32.  
  33. In fact there were several serious flaws in the Ada-83 language
  34. that made development of hosted applications in Ada-83 more difficult
  35. than developing them in C or C++.  
  36.  
  37.  >It is unreasonable to expect any validation suite to find all cases
  38.  >where a compiler diverges from the standard.  Arguably the ACVC tests
  39.  >should be / have been more extensive though.
  40.  
  41. The existence of the validation process is often given as an
  42. advantage of Ada over C and C++.  Now you are admitting that
  43. validation is a political process, and has almost no technical value.
  44.  
  45.  >Bugs in compilers are primarily the compiler vendors fault.  
  46.  
  47. Right, but I was unsuccessful in getting my compiler vendors interested
  48. in fixing their bugs.  This was yet another reason not to use Ada.
  49.  
  50.  >With the arrival GNAT, the commercial vendors have some real
  51.  >competition in terms of compiler quality.  If they don't come up to
  52.  >scratch, they are liable to lose market share.
  53.  
  54. There never seemed to be enough licensees to allow the compiler
  55. vendors to create a decent product in the early 90's; has this
  56. changed, or will GNAT be the only game in town?  That's not
  57. necessarily bad; I like public-domain software.  
  58.  
  59. >There are emerging public domain X and MOTIF bindings for Ada that
  60. >(assuming they are available with GNAT sometime soon) are IMO likely
  61. >to become defacto standards.
  62.  
  63. Emerging? Available soon?  MOTIF is eight years old; X ten.  
  64. While the Ada community has been trying to reach consensus on
  65. an X windows/MOTIF binding, the UNIX community has invented
  66. and widely adopted a whole new language (Tcl/Tk) for GUI development
  67. that is now used to develop commercial mission-critical software
  68. in the telecommunications industry.
  69.  
  70. Rightly or wrongly, many new software systems are designed initially
  71. with C and C++ APIs.  It seems doubtful that the Ada community will
  72. ever grow large enough to be able to produce and standardize on 
  73. Ada language bindings to new systems in a timely manner.
  74.  
  75. >>The lack of industry standard Ada bindings to these common OS
  76. >>services combined with the high expense and poor quality of the
  77. >>available Ada-83 compilers made development a medium-scale portable
  78. >>UNIX application in Ada much more expensive and difficult than
  79. >>developing the same application in C.
  80. >
  81. >Yes.  But given recent (though belated) standardisation activities and
  82. >the increasing influence of the GNU / FSF movement in the Ada
  83. >community, one would hope that this should be less of a problem in the
  84. >future.
  85.  
  86. I agree; within five years I predict the DoD mandate will be quietly
  87. repealed (or largely ignored) and Ada will go the way of APL.
  88.  
  89. By the way, I programmed in Ada-83 for three years and there was much
  90. to like about the language, but Ada advocates (and apparently the language
  91. designers) seldom seem to understand the practical considerations that
  92. prohibit the use of Ada for developing typical hosted applications.
  93.  
  94. >>To use Ada in my work today, I would 
  95. >>require an API to CORBA, 
  96. >
  97. >Available now or soon from at least two commercial ORB vendors; i.e. look at 
  98. >the following
  99. >
  100. >   http://alsp.arpa.mil/corba-ada/ada-products.html
  101. >
  102. >Note that the CORBA standard language bindings for Ada are expected to be
  103. >formally approved at the OMG board meeting that happens on March 20th (for
  104. >memory)
  105. >
  106.  
  107. I hope they are better than the abominable C++ bindings.
  108. -- 
  109. Kevin Cline
  110.